home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pppext-requirements-00.txt < prev    next >
Text File  |  1993-09-15  |  51KB  |  1,378 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                     Drew D Perkins
  8. Internet Draft                                Carnegie Mellon University
  9. expires April 1994                                        September 1993
  10.  
  11.  
  12.      Requirements for an Internet Standard Point-to-Point Protocol
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document is the product of the Point-to-Point Protocol Working
  19.    Group of the Internet Engineering Task Force (IETF).  Comments should
  20.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  21.  
  22.    Distribution of this memo is unlimited.
  23.  
  24.    This document is an Internet Draft.  Internet Drafts are working
  25.    documents of the Internet Engineering Task Force (IETF), its Areas,
  26.    and its Working Groups.  Note that other groups may also distribute
  27.    working documents as Internet Drafts.
  28.  
  29.    Internet Drafts are draft documents valid for a maximum of six
  30.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  31.    other documents at any time.  It is not appropriate to use Internet
  32.    Drafts as reference material or to cite them other than as a
  33.    ``working draft'' or ``work in progress.''
  34.  
  35.    Please check the 1id-abstracts.txt listing contained in the
  36.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  37.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  38.    current status of any Internet Draft.
  39.  
  40. Abstract
  41.  
  42.    This document discusses the requirements for an Internet Standard
  43.    Data Link Layer protocol to be used with point-to-point links.
  44.    Although many industry standard protocols and ad hoc protocols
  45.    already exist for the data link layer, none are both complete and
  46.    sufficiently versatile to be accepted as an Internet Standard.  In
  47.    preparation to designing such a protocol, the features necessary to
  48.    qualify a point-to-point protocol as an Internet Standard are
  49.    discussed in detail.  An analysis of the strengths and weaknesses of
  50.    several existing protocols on the basis of these requirements
  51.    demonstrates the failure of each to address key issues.
  52.  
  53.       Historical Note: This was the design requirements document
  54.       followed for RFC-1134 through the present.  It is now published
  55.  
  56.  
  57.  
  58. Perkins                  expires in six months                  [Page i]
  59. DRAFT             Point-to-Point Protocol Requirements   September 1993
  60.  
  61.  
  62.       for completeness and future guidance.
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Perkins                  expires in six months                 [Page ii]
  114. DRAFT             Point-to-Point Protocol Requirements   September 1993
  115.  
  116.  
  117. 1.  Introduction
  118.  
  119.    In the last few years, the Internet has seen explosive growth in the
  120.    number of hosts supporting IP [1].  The vast majority of these hosts
  121.    are connected to Local Area Networks (LANs) of various types,
  122.    Ethernet being the most common.  Most of the other hosts are
  123.    connected through Wide Area Networks (WANs), such as X.25 style
  124.    Public Data Networks (PDNs).
  125.  
  126.    Relatively few of these hosts are connected with simple point-to-
  127.    point links.  Yet, point-to-point serial links are among the oldest
  128.    methods of data communications, and almost every host supports
  129.    point-to-point connections.  For example, asynchronous RS-232-C
  130.    interfaces are essentially ubiquitous.
  131.  
  132.    One reason for the small number of point-to-point IP links is the
  133.    lack of a single established encapsulation protocol.  There are
  134.    plenty of non-standard (and at least one de facto standard)
  135.    encapsulation protocols available, but there is not one which has
  136.    been agreed upon as an Internet Standard.
  137.  
  138.    A number of protocols have been proposed to the Internet community in
  139.    the past, but no consensus has been reached as to which protocol
  140.    should be adopted as a standard.  The reason may be that these
  141.    proposals often address specific problems rather than providing
  142.    general purpose service.  For example, one of the most successful
  143.    protocols to-date has been Rick Adam's SLIP protocol for BSD UNIX
  144.    [9].  SLIP provides only the most rudimentary support for sending IP
  145.    datagrams over asynchronous serial lines, and ignores issues such as
  146.    the use of protocols other than IP and the use of synchronous links.
  147.  
  148.    The same data link layer protocol used for transmission of IP packets
  149.    should concurrently support the use of other existing protocols such
  150.    as XNS IP, DECnet and ISO CLNP.  This protocol should also support as
  151.    many point-to-point physical and data link layers as possible.  This
  152.    includes, but is not limited to, asynchronous, character-oriented
  153.    synchronous (BISYNC and DDCMP [15]), and bit-oriented synchronous
  154.    (HDLC [10] and X.25 LAPB [11]) links.
  155.  
  156.    This document proposes a set of requirements for an Internet Standard
  157.    point-to-point protocol (ISPPP).  Its purpose is not to propose any
  158.    one design for the standard; any solutions outlined in the text are
  159.    intended only as examples, and do not preclude other implementations.
  160.  
  161.    The document is divided into four major sections.  The first section
  162.    defines a number of technical terms used in this document.  The
  163.    second section lists the proposed requirements and details some
  164.    issues that are ignored by other protocols.  The third section
  165.  
  166.  
  167.  
  168. Perkins                  expires in six months                  [Page 1]
  169. DRAFT             Point-to-Point Protocol Requirements   September 1993
  170.  
  171.  
  172.    attempts to clarify a number of non-requirements.  The fourth section
  173.    analyzes existing protocols in light of the proposed requirements and
  174.    discusses the failure of each to address key issues.
  175.  
  176.  
  177. 1.1.  Definitions of Terms
  178.  
  179.    This section defines many of the terms which will be used in further
  180.    sections of this document.  The terms "layer" and "level" are used
  181.    extensively and refer to protocol layers as defined by the
  182.    International Organization For Standardization's Reference Model
  183.    (ISORM) standard.  In particular, the terms Physical Layer, Data Link
  184.    Layer and Network Layer refer to layers one, two and three
  185.    respectively of the ISORM.  A "higher layer" refers to one with a
  186.    numerically larger layer number.
  187.  
  188.    datagram
  189.       The unit of transmission in the network layer (such as IP).  A
  190.       datagram may be encapsulated in one or more packets (q.v.) passed
  191.       to the data link layer.
  192.  
  193.    data link layer
  194.       Layer two in the ISO reference model.  Defines how bits
  195.       transmitted and received by the physical layer are recognized as
  196.       bytes and frames.  May also define procedures for error detection
  197.       and correction, sequencing and flow control.
  198.  
  199.    fragment
  200.       The result of fragmentation.  Fragmentation at the network layer
  201.       breaks large datagrams into multiple parts less than or equal to
  202.       the size of the packets passed to the data link layer.
  203.       Fragmentation at the data link layer breaks large packets into
  204.       multiple frames.
  205.  
  206.    frame
  207.       The unit of transmission at the data link layer.  A frame may
  208.       include a header and/or a trailer along with some number of units
  209.       of data.
  210.  
  211.    framing protocol
  212.       A protocol at the data link level for marking the beginning and
  213.       end of a frame transmitted across a link.
  214.  
  215.    internet
  216.       An interconnected system of networks tied together by a common
  217.       "internet protocol" providing a common and consistent network
  218.       address structure.
  219.  
  220.  
  221.  
  222.  
  223. Perkins                  expires in six months                  [Page 2]
  224. DRAFT             Point-to-Point Protocol Requirements   September 1993
  225.  
  226.  
  227.    Internet
  228.       Specifically refers to the IP Internet.
  229.  
  230.    Internet Standard Point-to-Point Protocol (ISPPP)
  231.       A point-to-point protocol which is declared an official Internet
  232.       Standard.  This protocol does not yet exist, but its proposed
  233.       characteristics are presented in this paper.
  234.  
  235.    Maximum Transmission Unit (MTU)
  236.       The maximum allowable length for a packet (q.v.) transmitted over
  237.       a point-to-point link without incurring network layer
  238.       fragmentation.
  239.  
  240.    network layer
  241.       Layer three in the ISO reference model.  Responsible for routing
  242.       packets (q.v) between physical networks.
  243.  
  244.    octet
  245.       A unit of transmission consisting of 8 bits.  On most machines an
  246.       octet is the same as a byte or a character, but this need not be
  247.       true.
  248.  
  249.    packet
  250.       The unit of transmission passed across the interface between the
  251.       network layer and the data link layer.  A packet is usually mapped
  252.       to a frame (q.v); the exception is when data link layer
  253.       fragmentation is being performed.
  254.  
  255.    physical layer
  256.       The first layer in the ISO reference model.  Describes electrical,
  257.       mechanical and timing characteristics of a link.
  258.  
  259.    point-to-point protocol (ppp)
  260.       A data link layer protocol for the transmission of packets (q.v.)
  261.       over a point-to-point link.  In the following discussion, the
  262.       acronym "ppp" refers to any generic point-to-point protocol.
  263.  
  264.    serial line IP (slip)
  265.       Often incorrectly used as a synonym for "point-to-point protocol",
  266.       "slip" specifically refers to any protocol for the transmission of
  267.       IP datagrams over a serial point-to-point line.
  268.  
  269.    SLIP
  270.       Although many proposed protocols are named "SLIP", this document
  271.       will use SLIP (uppercase) to refer to Rick Adam's slip (q.v.) for
  272.       BSD UNIX [9].
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Perkins                  expires in six months                  [Page 3]
  279. DRAFT             Point-to-Point Protocol Requirements   September 1993
  280.  
  281.  
  282. 2.  Requirements
  283.  
  284.    In order for a point-to-point protocol to be accepted by the Internet
  285.    community it must adequately address many requirements.  This section
  286.    itemizes and discusses the proposed requirements.  Although the main
  287.    emphasis of the discussion is on protocol architecture requirements,
  288.    implementation requirements are sometimes discussed as well.
  289.  
  290.    These particular requirements were chosen to assure that the ISPPP
  291.    adequately serves the needs of its users.  Some of these needs are
  292.    universal and dictate clear requirements for the protocol; for
  293.    example, a packet framing protocol is a fundamental necessity.  Other
  294.    needs are more specific and may even be conflicting.  Connection
  295.    liveness determination is very important on some links but can be
  296.    very expensive on others.  A standard protocol must address all of
  297.    these needs; in particular, it must be able to resolve conflicts
  298.    effectively.
  299.  
  300.    Resolving these conflicts requires that a protocol feature have both
  301.    enabled and disabled modes and that these modes must be compatible
  302.    with each other.  The enabled mode allows the protocol to solve
  303.    problems in environments where they exist.  The disabled mode allows
  304.    problems to be ignored in environments where they do not exist.  To
  305.    assure interoperabilty, implementations are required to support both
  306.    modes and allow the user (not necessarily human) to dynamically
  307.    choose which is appropriate.
  308.  
  309.    This is essentially the same solution used in the User Datagram
  310.    Protocol (UDP) [2].  The UDP datagram checksum may be computed
  311.    (enabled mode) or it may not (disabled mode).  Compatibility is
  312.    maintained by requiring the checksum to be transmitted as zero in
  313.    disabled mode and ignored when received as zero in either mode.
  314.    Implementations of UDP are generally encouraged to support both modes
  315.    but allow the application to choose modes.
  316.  
  317.  
  318. 2.1.  Simplicity
  319.  
  320.    The ISPPP must be simple.  The Internet architecture very carefully
  321.    places the most complexity in the transport layer (that is, TCP).
  322.    The internetwork layer (IP) is a fairly simple, almost stateless
  323.    protocol providing an unreliable datagram service.  The data link
  324.    layer need provide no more capability than the IP protocol; no error
  325.    correction, sequencing or flow control is necessary.  Including these
  326.    would in most cases needlessly duplicate the capabilities of the
  327.    transport layer, and might possibly decrease efficiency.  This is not
  328.    to say that these capabilities must never be included; there are some
  329.    cases which may warrant them.  For instance, very noisy links may be
  330.  
  331.  
  332.  
  333. Perkins                  expires in six months                  [Page 4]
  334. DRAFT             Point-to-Point Protocol Requirements   September 1993
  335.  
  336.  
  337.    more efficiently handled using a more complex data link layer
  338.    protocol such as CCITT's LAPB.  Nevertheless, the watchword for a
  339.    point-to-point protocol should be simplicity.
  340.  
  341.    A simple design also decreases the incidence of programming errors,
  342.    thereby increasing the likelihood of interoperability among different
  343.    implementations.  Since interoperability is a primary goal of
  344.    standardization, this is another strong argument for simplicity.
  345.  
  346.  
  347. 2.2.  Transparency
  348.  
  349.    The ISPPP must be transparent to higher layers.  The protocol must
  350.    not place any constraints on transmitted data.  All ISPPP data,
  351.    including higher level headers as well as data, must be transported
  352.    unmodified end-to-end.  No restrictions are placed on how the ISPPP
  353.    accomplishes this.  For example, if the ISPPP uses a particular
  354.    character for framing, it must also provide some way of
  355.    disambiguating higher level data containing that character from a
  356.    framing character (such as escaping or bit-stuffing).  This is mainly
  357.    an issue for the data link and physical layer protocols incorporated
  358.    into the ISPPP.
  359.  
  360.  
  361. 2.3.  Packet Framing
  362.  
  363.    The ISPPP must be able to correctly and efficiently frame packets.  A
  364.    receiver must be able to locate correctly the beginning and end of
  365.    each transmitted packet.  Within each packet, the receiver must be
  366.    able to identify the boundaries of each octet.  Finally, within each
  367.    octet, each bit must be located and identified.  No restrictions
  368.    other than those specified in this document are placed on the packet
  369.    framing protocol.
  370.  
  371.  
  372. 2.4.  Bandwidth Efficiency
  373.  
  374.    The ISPPP must make efficient use of available bandwidth.  For
  375.    example, a ppp which requires 50% of the link bandwidth for overhead
  376.    would be unacceptable.  At most, the ppp overhead may impose a few
  377.    percent reduction in raw link bandwidth.
  378.  
  379.  
  380. 2.5.  Protocol Processing Efficiency
  381.  
  382.    The processing of the ISPPP headers must typically be very fast and
  383.    efficient.  The format for data packets should be very simple in the
  384.    normal case, without complex field checking.
  385.  
  386.  
  387.  
  388. Perkins                  expires in six months                  [Page 5]
  389. DRAFT             Point-to-Point Protocol Requirements   September 1993
  390.  
  391.  
  392. 2.6.  Protocol Multiplexing
  393.  
  394.    The ISPPP must support multiplexing of many higher level protocols.
  395.    Although the Internet community is interested mainly in IP, co-
  396.    existence of other protocols is frequently required.  IP networks
  397.    must often support additional protocols such as DECnet, XNS, and ISO.
  398.    For point-to-point links to connect gateways on geographically
  399.    separated Local Area Networks (LANs), the ISPPP must simultaneously
  400.    support all protocols implemented on both the LANs and the gateways.
  401.    This suggests that the ISPPP must include a protocol type field or
  402.    other multiplexing scheme.  Given the large number of protocols, the
  403.    potential use of the protocol type field as a data compression aid,
  404.    and the experimental nature of the Internet, eight bits of type field
  405.    are not sufficient.  Sixteen bits of type field are suggested,
  406.    although twelve bits (4096 protocols) should suffice.
  407.  
  408.  
  409. 2.7.  Multiple Physical and Data Link Layer Protocols
  410.  
  411.    The ISPPP must support a multiplicity of physical and data link layer
  412.    protocols.  Many types of point-to-point links exist.  Links can be
  413.    serial or parallel, synchronous or asynchronous, low speed or high
  414.    speed, electrical or optical.  Standards are required for the
  415.    transmission of IP datagrams over each type of commonly used link.
  416.    The ISPPP must not inhibit the use of any type of link.
  417.  
  418.    The ISPPP must provide support for at least the following types of
  419.    links:
  420.  
  421.       Full duplex asynchronous RS-232 [3] links with 8 bits of data and
  422.       no parity, ranging in speeds from 300 to 19.2k baud and higher.
  423.  
  424.       Full duplex bit-oriented synchronous links including RS-422, RS-
  425.       423, V.35 and T1.
  426.  
  427.    Other links should be standardized as the need arises.
  428.  
  429.  
  430. 2.8.  Error Detection
  431.  
  432.    The ISPPP must provide some form of basic error detection.  Most
  433.    network and transport layer protocols provide mechanisms to detect
  434.    corrupted packets.  However, some protocols expect error free
  435.    transmission and either provide error detection only on a conditional
  436.    basis or do not provide it at all.  It is the consensus of the
  437.    Internet community that error detection should always be implemented
  438.    end-to-end, but the ISPPP must provide its own error detection in the
  439.    form of a checksum, Cyclic Redundancy Count (CRC) or other frame
  440.  
  441.  
  442.  
  443. Perkins                  expires in six months                  [Page 6]
  444. DRAFT             Point-to-Point Protocol Requirements   September 1993
  445.  
  446.  
  447.    check mechanism.  Error correction is not required but may be
  448.    desirable in some circumstances.
  449.  
  450.  
  451. 2.9.  Standardized Maximum Packet Length (MTU)
  452.  
  453.    The ISPPP must have a standardized default maximum packet length for
  454.    each type of point-to-point link.  This standardization helps to
  455.    promote interoperable implementations.  Higher layer protocols must
  456.    not attempt to transmit packets longer than the MTU.  If a higher
  457.    layer protocol does try to transmit a packet which is too long, the
  458.    ISPPP must drop the packet and return an error.  The MTU may
  459.    potentially be changed from the default via some sort of explicit
  460.    negotiation or private agreement, but the default must be enforced in
  461.    all other cases.
  462.  
  463.  
  464. 2.10.  Switched and Non-Switched Media
  465.  
  466.    The ISPPP must be able to support both switched (dynamic) and non-
  467.    switched (static) point-to-point links.  A common example of a non-
  468.    switched link is a 3-wire asynchronous RS-232 cable which might
  469.    connect a host to a particular gateway.  Switched media may be
  470.    exemplified by connections over a standard voice network or an
  471.    Integrated Services Digital Network (ISDN).  Links over ISDN are
  472.    currently rare, but are expected to become increasingly commonplace.
  473.    To be a viable standard, the ISPPP must be able to effectively
  474.    support both types of links.  Procedures for establishing switched
  475.    connections are beyond the scope of this document.
  476.  
  477.  
  478. 2.11.  Symmetry
  479.  
  480.    The ISPPP should operate symmetrically to maximize flexibility.  The
  481.    ISPPP must allow communications among any combination of gateways and
  482.    hosts.  One host may need to communicate directly with another host,
  483.    or it may be connected to a gateway to gain access to a whole
  484.    network.  A gateway may establish a connection to a single host in
  485.    order to deliver a packet, or it may connect to another gateway on a
  486.    permanent or transient basis.  Symmetry is destroyed by pre-assigned
  487.    static roles, such as master and slave or gateway and host.  If
  488.    necessary, roles may be dynamically determined on a per connection
  489.    basis.
  490.  
  491.  
  492. 2.12.  Connection Liveness
  493.  
  494.    The ISPPP must include a mechanism to automatically determine when a
  495.  
  496.  
  497.  
  498. Perkins                  expires in six months                  [Page 7]
  499. DRAFT             Point-to-Point Protocol Requirements   September 1993
  500.  
  501.  
  502.    link is functioning properly and when it is defunct.  This mechanism
  503.    should be enabled by default, but the protocol and all
  504.    implementations must allow this mechanism to be disabled.
  505.  
  506.    When enabled, this mechanism should discover changes in a link's
  507.    status in a timely fashion -- no more than a few minutes.  Continuing
  508.    to utilize a link which is down often causes routing problems
  509.    commonly referred to as "black holes".  These problems can be hard to
  510.    find and diagnose.  By automatically detecting a failing link, a
  511.    point-to-point protocol can avoid such problems, and also provide a
  512.    powerful tool for a network manager trying to locate and remedy the
  513.    fault.
  514.  
  515.    When a point-to-point connection is not functioning properly, it must
  516.    be declared "down" for the purposes of routing packets for higher
  517.    level protocols.  In order to certify a link "up", the systems on
  518.    either end of the link must be able to successfully exchange packets.
  519.    In other words, the systems at both ends must be able both to
  520.    transmit and to receive packets, and the link must be able to
  521.    transport packets in both directions.  Links are defined to be "down"
  522.    at initialization, their liveness must be verified before they may be
  523.    declared "up".
  524.  
  525.    This feature may be disabled in situations where connection status
  526.    determination is "expensive".  For example, a link may traverse a
  527.    Public Data Network (such as TELENET or TYMNET) which accounts for
  528.    bandwidth utilization.  Constant pinging would result in charges
  529.    being accrued even in the absence of useful communications.
  530.  
  531.  
  532. 2.13.  Loopback Detection
  533.  
  534.    The ISPPP must be capable of automatically detecting a looped-back
  535.    link without operator assistance.  Modems and other communications
  536.    gear are often placed in a loopback mode to aid in diagnosis of
  537.    circuit failures.  Detection of this condition must take no longer
  538.    than one period of the liveness protocol.  While the link is in
  539.    loopback mode, each end of the link must declare the other end to be
  540.    unreachable.  However, to aid in diagnosis, each end of the link may
  541.    declare itself reachable for any higher-level protocol which
  542.    distinguishes between the two ends of the link.
  543.  
  544.  
  545. 2.14.  Misconfiguration Detection
  546.  
  547.    The ISPPP must be able to quickly detect misconfigured point-to-point
  548.    connections.  A connection which is misconfigured must never be
  549.    declared to be up.  Many systems, gateways in particular, have more
  550.  
  551.  
  552.  
  553. Perkins                  expires in six months                  [Page 8]
  554. DRAFT             Point-to-Point Protocol Requirements   September 1993
  555.  
  556.  
  557.    than one point-to-point connection.  When many cables terminate
  558.    within a small area, the possibility for confusion abounds.  It
  559.    becomes very easy to mistakenly plug a cable into the wrong
  560.    connector, or even to swap cables.  The protocol should do its best
  561.    to provide protection against these errors by verifying the remote
  562.    end's identity whenever possible before marking an interface as
  563.    operational.  The purpose of this verification is not rigorous
  564.    authentication but the detection of simple errors.
  565.  
  566.  
  567. 2.15.  Network Layer Address Negotiation
  568.  
  569.    The ISPPP must allow network layer (such as IP) addresses to be
  570.    negotiated.  The negotiation algorithm should be as simple as
  571.    possible and must be guaranteed to terminate in all cases.  Many
  572.    network layer protocols and implementations are required to know the
  573.    addresses at both ends of a point-to-point link before packets may be
  574.    routed.  These addresses may be statically configured, but it may
  575.    sometimes be necessary or convenient for these addresses be
  576.    dynamically ascertained at connection establishment.  This is
  577.    especially important when switched media are used.  For example, a
  578.    dial-up IP gateway must know the IP address of its peer before
  579.    packets can be successfully routed.  This address can be either
  580.    statically or dynamically configured.  In the former case, the
  581.    gateway's peer must therefore learn the static address (static with
  582.    respect to the gateway).  In the latter situation, the gateway must
  583.    dynamically learn the address used by its peer.
  584.  
  585.  
  586. 2.16.  Data Compression Negotiation
  587.  
  588.    The ISPPP must provide a way to negotiate the use of data compression
  589.    algorithms.  This mechanism should be as simple as possible and must
  590.    be guaranteed to terminate in all cases.  The protocol is not
  591.    required to standardize any data compression algorithms; conforming
  592.    implementations of the protocol therefore may refuse to do data
  593.    compression when negotiating (refusal to do data compression always
  594.    takes precedence over an offer to do it).  However, to allow the use
  595.    of data compression between consenting systems, the point-to-point
  596.    protocol must not impede the use of data compression.  In fact, it
  597.    should be possible to use multiple, independent data compression
  598.    schemes simultaneously.
  599.  
  600.    Because data compression algorithms are still very experimental in
  601.    the Internet environment, it is likely that many different algorithms
  602.    will be tried.  The negotiation protocol must distinguish between
  603.    these different algorithms to ensure that data compression is not
  604.    enabled unless the same algorithm or algorithms are used at both ends
  605.  
  606.  
  607.  
  608. Perkins                  expires in six months                  [Page 9]
  609. DRAFT             Point-to-Point Protocol Requirements   September 1993
  610.  
  611.  
  612.    of the connection.  The number of such supported algorithms must be
  613.    easily extensible.
  614.  
  615.  
  616. 2.17.  Extensibility and Option Negotiation
  617.  
  618.    The ISPPP must allow for future extensions in a flexible way.  The
  619.    Internet will never cease to evolve.  Changes in technology and user
  620.    demands create new requirements.  To function effectively as a
  621.    standard, the protocol must have the ability to evolve along with its
  622.    environment.
  623.  
  624.    To accomplish this, the ISPPP should be designed to be as extensible
  625.    as possible and to allow for experimentation within the guidelines of
  626.    the other requirements presented in this document.  A proposed
  627.    solution is to specify an option negotiation protocol.  The option
  628.    negotiation protocol could be used for the negotiation of network
  629.    layer addresses, data compression schemes, MTU, encryption, etc.  The
  630.    option negotiation protocol must itself be extensible; it should
  631.    allow the negotiation of a large number of future options and it
  632.    should allow the use of other types of point-to-point links and
  633.    encapsulation schemes.
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663. Perkins                  expires in six months                 [Page 10]
  664. DRAFT             Point-to-Point Protocol Requirements   September 1993
  665.  
  666.  
  667. 3.  Non-Requirements
  668.  
  669.    This section discusses functionality which is explicitly not
  670.    required.  These functions may potentially be included in
  671.    implementations as long as the inclusion does not violate any of the
  672.    requirements itemized in the previous section.
  673.  
  674.  
  675. 3.1.  Error Correction
  676.  
  677.    As discussed above in the sections on Simplicity and Error Detection,
  678.    error correction is the responsibility of the transport layer and is
  679.    not required in a point-to-point protocol.  However, on links with
  680.    high error rates, performance may be increased by adding error
  681.    correction at the data link level.  Therefore, the ISPPP must not
  682.    prevent the addition of error correction by private agreement, even
  683.    though such mechanisms are not required.
  684.  
  685.  
  686. 3.2.  Flow Control
  687.  
  688.    Flow control (such as XON/XOFF) is not required.  Any implementation
  689.    of the ISPPP is expected to be capable of receiving packets at the
  690.    full rate possible for the particular data link and physical layers
  691.    used in the implementation.  If higher layers cannot receive packets
  692.    at the full rate possible, it is up to those layers to discard
  693.    packets or invoke flow control procedures.  As discussed above, end-
  694.    to-end flow control is the responsibility of the transport layer.
  695.    Including flow control within a point-to-point protocol often causes
  696.    violation of the simplicity requirement.
  697.  
  698.  
  699. 3.3.  Sequencing
  700.  
  701.    Sequencing of packets is not required.  The ISPPP need provide no
  702.    more service than the IP protocol, an unreliable datagram service
  703.    which is free to reorder packets.  In fact, it is specifically
  704.    allowed to reorder packets based upon some type-of-service criteria
  705.    implemented in higher-level protocols.
  706.  
  707.  
  708. 3.4.  Backward Compatibility
  709.  
  710.    There is no requirement for the ISPPP to provide backward
  711.    compatibility with any other point-to-point protocol.  First, there
  712.    are no official Internet Standards with which backward compatibility
  713.    must be maintained.  Second, attempting to maintain backward
  714.    compatibility may lead to needless restrictions on the new protocol.
  715.  
  716.  
  717.  
  718. Perkins                  expires in six months                 [Page 11]
  719. DRAFT             Point-to-Point Protocol Requirements   September 1993
  720.  
  721.  
  722.    However, there is no need for the designers of the ISPPP to go out of
  723.    their way to inhibit backward compatibility.
  724.  
  725.  
  726. 3.5.  Multi-Point Links
  727.  
  728.    There is no requirement for supporting multi-point links.  These
  729.    links are sufficiently rare that the benefits of supporting them are
  730.    outweighed by the added complexity their support would introduce into
  731.    the ISPPP.  Furthermore, it is unlikely that many new types of
  732.    multi-point links will be introduced in the foreseeable future.
  733.  
  734.       Historical Note: Since this was written, considerable effort has
  735.       been expended in new multi-point links, including Switched
  736.       Multimegabit Data Service, Frame Relay, and Asynchronous Transfer
  737.       Mode.  The crystal ball was apparently clouded.
  738.  
  739.  
  740. 3.6.  Half-Duplex or Simplex Links
  741.  
  742.    Support for half-duplex or simplex links is not required.  These
  743.    types of links are not in common use in the current Internet.  Half-
  744.    duplex links require some method of turning the line around.  The
  745.    ISPPP need not have an explicit mechanism for handling line turn-
  746.    around.  Such support might possibly be added in the future via the
  747.    required extension mechanism.
  748.  
  749.  
  750. 3.7.  7-bit Asynchronous RS-232 Links
  751.  
  752.    The use of asynchronous RS-232 need not support 7-bit links.  8-bit
  753.    links are predominant in the Internet environment and supporting 7-
  754.    bit links introduces unnecessary complexity.
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773. Perkins                  expires in six months                 [Page 12]
  774. DRAFT             Point-to-Point Protocol Requirements   September 1993
  775.  
  776.  
  777. 4.  Prior Work On PPP Protocols
  778.  
  779. This section reviews a number of existing point-to-point and data link
  780. layer protocols and points out which of our requirements are not
  781. satisfied.
  782.  
  783. 4.1.  Internet Protocols
  784.  
  785. 4.1.1.  RFC 891 - DCN Local-Network Protocols, Appendix A
  786.  
  787.    In Appendix A of RFC 891, "DCN Local-Network Protocols" [4], D.L.
  788.    Mills describes the data link layer packet formats used by the
  789.    Fuzzball system for asynchronous, character-oriented synchronous,
  790.    DDCMP, HDLC, ARPANET 1822, X.25 LAPB and ethernet links.  These
  791.    protocols meet the stated requirements for simplicity, transparency,
  792.    packet framing and efficiency, but fall short of many of the others.
  793.    Most of these protocols assume the use of the IP protocol, and do not
  794.    include any type of protocol demultiplexing field.  No error
  795.    detection mechanism is provided except when necessary to comply with
  796.    another standard such as ethernet.  RFC 891 does not mention the MTU
  797.    used for any of these links.  Other requirements such as loopback
  798.    detection and misconfiguration detection are not discussed.  Finally,
  799.    no option negotiation scheme is defined; without a protocol
  800.    demultiplexing field it would be difficult or impossible to include
  801.    one.
  802.  
  803.  
  804. 4.1.2.  RFC 914 - Thinwire Protocols
  805.  
  806.    RFC 914, "Thinwire Protocols" [5], discusses the use of low speed
  807.    links in the Internet.  This document places its main emphasis on
  808.    decreasing round-trip delay and increasing link efficiency with the
  809.    help of header compression (vs. data compression) techniques.  Three
  810.    "Thinwire" protocols are discussed, Thinwire I, Thinwire II and
  811.    Thinwire III.  The latter two protocols require the use of a reliable
  812.    data link layer protocol; one such protocol, "SLIP" (not to be
  813.    confused with Rick Adams' SLIP), is proposed in Appendix D of the
  814.    RFC.  As proposed, "SLIP" does not meet many of the stated
  815.    requirements.  Although not terribly complex, as a reliable, error
  816.    detecting and correcting protocol, it is not "simple".  The 32 octet
  817.    packet size makes it inefficient for large or uncompressed packets,
  818.    requiring complex fragmentation and reassembly.  The use of other
  819.    than asynchronous links is not mentioned.  The entire reliable link
  820.    layer would be redundant over LAPB links.  There is no mechanism for
  821.    option negotiation or future extensibility.
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828. Perkins                  expires in six months                 [Page 13]
  829. DRAFT             Point-to-Point Protocol Requirements   September 1993
  830.  
  831.  
  832. 4.1.3.  RFC 916 - Reliable Asynchronous Transfer Protocol
  833.  
  834.    RFC 916 [6] presents RATP, the Reliable Asynchronous Transfer
  835.    Protocol.  RATP provides error detection and correction, sequencing
  836.    and flow control across a point-to-point connection.  It is directed
  837.    towards full duplex RS-232 links although it is useful for other
  838.    point-to-point links.  Although the author claims that RATP is not as
  839.    complex as some other protocols, it is far from simple.  RATP solves
  840.    many of the problems which we have labeled non-requirements and fails
  841.    to solve many of our stated requirements.  Specifically, RATP does
  842.    not support option negotiation and has no mechanism for future
  843.    extensibility.  Since RFC 916 was published, no consensus has emerged
  844.    advocating RATP.  For these reasons RATP is not recommended as the
  845.    ISPPP.
  846.  
  847.  
  848. 4.1.4.  RFC 935 - Reliable Link Layer Protocols
  849.  
  850.    RFC 935 [7] is a rebuttal to the protocols proposed in RFCs 914 and
  851.    916.  J. Robinson discusses existing and widely-used national and
  852.    international standards which meet the needs addressed by the two
  853.    prior RFCs.  The standards reviewed include character-oriented
  854.    asynchronous and synchronous (bisynch) protocols and bit-oriented
  855.    synchronous protocols.  RFC 935 does not present any higher level
  856.    issues such as option negotiation or extensibility.
  857.  
  858.  
  859. 4.1.5.  RFC 1009 - Requirements for Internet Gateways
  860.  
  861.    Section 3 of RFC 1009, "Constituent Network Interfaces" [8], briefly
  862.    discusses requirements for transmission of IP datagrams over a number
  863.    of types of point-to-point links including X.25 LAPB, HDLC framed
  864.    synchronous links, Xerox Synchronous Point-to-Point synchronous lines
  865.    and the MIT Serial Line Framing Protocol for asynchronous lines.  RFC
  866.    1009 merely mentions these as reasonable candidates and does not go
  867.    into depth on any of them.  All are discussed further in this
  868.    document.
  869.  
  870.  
  871. 4.1.6.  RFC 1055 - Serial Line IP
  872.  
  873.    Rick Adams' Serial Line IP (SLIP) protocol [9] has become something
  874.    of a de facto standard due to the popularity of the 4.2 and 4.3BSD
  875.    UNIX operating systems.  SLIP is easily added to 4.2 systems and is
  876.    included with 4.3.  Many other TCP/IP implementation have added SLIP
  877.    implementations in order to be compatible.  Yet SLIP is not a real
  878.    standard; the protocol was only recently published in RFC form.
  879.    Before RFC 1055 it was specified in the SLIP source code.
  880.  
  881.  
  882.  
  883. Perkins                  expires in six months                 [Page 14]
  884. DRAFT             Point-to-Point Protocol Requirements   September 1993
  885.  
  886.  
  887.    SLIP does not meet most of the requirements set forth above.  SLIP
  888.    certainly meets the requirement for simplicity, and also meets the
  889.    requirements for transparency and bandwidth efficiency.  But SLIP
  890.    only provides for sending IP packets over asynchronous serial lines.
  891.    Since it provides no higher level protocol field for demultiplexing,
  892.    SLIP cannot support multiple concurrent higher level protocols.
  893.    Providing only a framing protocol, SLIP would be entirely redundant
  894.    when used with a LAPB synchronous link.  SLIP includes absolutely no
  895.    mechanism for error detection, not even parity.  Again due to its
  896.    lack of a protocol type field, SLIP does not support any type of
  897.    option negotiation or extensibility.
  898.  
  899.  
  900. 4.2.  International Protocols
  901.  
  902. 4.2.1.  ISO 3309 - HDLC Frame Structure
  903.  
  904.    ISO 3309 [10], the HDLC frame structure, is a simple data link layer
  905.    protocol which provides framing of packets transmitted over bit-
  906.    oriented synchronous links.  Special flag sequences mark the
  907.    beginning and end of frames and bit stuffing allows data containing
  908.    flag characters to be transmitted.  A 16-bit Frame Check Sequence
  909.    provides error detection.
  910.  
  911.    By itself, the HDLC frame structure does not meet most of the
  912.    requirements.  HDLC does not provide protocol multiplexing, standard
  913.    MTUs, fault detection or option negotiation.  There is no mechanism
  914.    for future extensibility.
  915.  
  916.    Given the HDLC frame structure's wide acceptance and simplicity, it
  917.    may be an ideal building block for the ISPPP.
  918.  
  919.  
  920. 4.2.2.  ISO 6256 - HDLC Balanced Class of Procedures
  921.  
  922.    ISO 6256, the HDLC Balanced Class of Procedures, specifies a data
  923.    link layer protocol which provides error correction, sequencing and
  924.    flow control.  ISO 6256 builds on ISO 3309 and ISO 4335, HDLC
  925.    Elements of Procedures.
  926.  
  927.    As far as meeting our requirements is concerned, ISO 6256 does not
  928.    provide any more utility than does ISO 3309.  The capabilities that
  929.    are provided are all considered unnecessary and overly complex.
  930.  
  931.  
  932. 4.2.3.  CCITT X.25 and X.25 LAPB
  933.  
  934.    CCITT recommendation X.25 [11] describes a network layer protocol
  935.  
  936.  
  937.  
  938. Perkins                  expires in six months                 [Page 15]
  939. DRAFT             Point-to-Point Protocol Requirements   September 1993
  940.  
  941.  
  942.    providing error-free, sequenced, flow controlled virtual circuits.
  943.    X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335
  944.    and 6256.  Neither X.25 LAPB or full LAPB meet any more of our
  945.    requirements than the ISO protocols.
  946.  
  947.  
  948. 4.2.4.  CCITT I.441 LAPD
  949.  
  950.    CCITT I.441 LAPD [12] defines the Link Access Procedure on the ISDN
  951.    D-Channel.  The data link layer of LAPD is very similar to that of
  952.    LAPB and fails meet the same requirements.
  953.  
  954.  
  955. 4.3.  Other Protocols
  956.  
  957. 4.3.1.  cisco Systems point-to-point protocols
  958.  
  959.    The cisco Systems gateway supports both asynchronous links using SLIP
  960.    and synchronous links using either simple HDLC framing, X.25 LAPB or
  961.    full X.25.  The HDLC framing procedure includes a four byte header.
  962.    The first octet (address) is either 0x0F (unicast intent) or 0x8F
  963.    (multicast intent).  The second octet (control byte) is left zero and
  964.    is not checked on reception.  The third and fourth octets contain a
  965.    standard 16 bit Ethernet protocol type code.
  966.  
  967.    A "keepalive" or "beaconing" protocol is used to ensure the two-way
  968.    connectivity of the serial line.  Each end of the link periodically
  969.    sends two 32 bit sequence numbers to the other side.  One sequence
  970.    number is the local side's sequence number, the other is the sequence
  971.    number received from the other side.  Hearing the local sequence
  972.    number from the other side indicates that the link is working in both
  973.    directions.
  974.  
  975.    The keepalive protocol is extensible.  One extension is used to
  976.    default IP addresses on serial lines of systems without non-volatile
  977.    memory.  A request for address is sent to the remote side.  The
  978.    remote side responds with its own IP address and a subnet mask.  When
  979.    the querying side receives the reply, it checks if the host portion
  980.    of the remote address is either 1 or 2.  If so, the opposite address
  981.    is chosen for the local address.  If not, the protocol cannot be used
  982.    and we must rely on other address resolution means.  This protocol
  983.    assumes that each serial link uses one subnet or network number.
  984.  
  985.    LAPB assuming IP is another possible encapsulation.  A multi-protocol
  986.    extension of LAPB (multi-LAPB) includes a 16 bit Ethernet type code
  987.    after the address and control bytes and in front of the actual
  988.    protocol data.
  989.  
  990.  
  991.  
  992.  
  993. Perkins                  expires in six months                 [Page 16]
  994. DRAFT             Point-to-Point Protocol Requirements   September 1993
  995.  
  996.  
  997.    DDN X.25 and Commercial X.25 encapsulations are also supported.
  998.    Multiple protocols are supported by making protocol dependent CALL
  999.    REQUEST's.
  1000.  
  1001.  
  1002. 4.3.2.  MIT PC/IP framing protocol
  1003.  
  1004.    The MIT PC/IP framing protocol [13] provides a mechanism for the
  1005.    transmission of IP datagrams over asynchronous links.  The low-level
  1006.    protocol (LLP) sublayer provides encapsulation while the local net
  1007.    protocol provides multiplexing of IP datagrams and IP address request
  1008.    packets.  The protocol only allows host-to-gateway connections.
  1009.    Host-to-gateway flow control is provided by requiring the host to
  1010.    transmit request packets to the gateway until an acknowledgment is
  1011.    received.  Rudimentary IP address negotiation requires the host to
  1012.    ascertain its IP address from the gateway.
  1013.  
  1014.    The protocol does not implement error detection, connection status
  1015.    determination, fault detection or option negotiation.  Only
  1016.    asynchronous links are supported.
  1017.  
  1018.  
  1019. 4.3.3.  Proteon p4200 point-to-point protocol
  1020.  
  1021.    The Proteon p4200 multi-protocol router supports transmission of
  1022.    packets over bit-oriented synchronous links with a wide range of
  1023.    speeds (zero to 2 Mb/sec).  The p4200 point-to-point protocol
  1024.    encapsulates packets inside HDLC frames but does not use the HDLC
  1025.    address or control fields; these two octets are instead used for a
  1026.    16-bit type field.  The p4200 does use the HDLC frame check sequence
  1027.    trailer.  Protocol type numbers are ad hoc and do not correspond to
  1028.    any existing standard.  A simple liveness protocol detects dead
  1029.    connections.
  1030.  
  1031.    Although the Proteon protocol does meet many of our requirements, it
  1032.    does not meet our requirements for option negotiation.
  1033.  
  1034.  
  1035. 4.3.4.  Ungermann Bass point-to-point protocol
  1036.  
  1037.    The UB router supports synchronous links using simple HDLC framing.
  1038.    Neither the HDLC address or control field are used, IP datagrams are
  1039.    placed immediately after the HDLC flag.
  1040.  
  1041.    The UB protocol does not meet any of our requirements for fault
  1042.    detection or option negotiation.  No mechanism for future
  1043.    extensibility is currently defined.
  1044.  
  1045.  
  1046.  
  1047.  
  1048. Perkins                  expires in six months                 [Page 17]
  1049. DRAFT             Point-to-Point Protocol Requirements   September 1993
  1050.  
  1051.  
  1052. 4.3.5.  Wellfleet point-to-point protocol
  1053.  
  1054.    The Wellfleet router supports synchronous links using simple HDLC
  1055.    framing.  The HDLC framing procedure uses the HDLC address and places
  1056.    the Unnumbered Information (UI) command in all frames.  A simple
  1057.    header following the UI command provides a two octet type field using
  1058.    the same values as Ethernet.
  1059.  
  1060.    The Wellfleet protocol does not meet any of our requirements for
  1061.    fault detection or option negotiation.  No mechanism for future
  1062.    extensibility is currently defined, although one could be added.
  1063.  
  1064.  
  1065. 4.3.6.  XNS Synchronous Point-to-Point Protocol
  1066.  
  1067.    The Xerox Network Systems Synchronous Point-to-Point protocol (XNS
  1068.    PPP) [14] was designed to address most of the same issues that an
  1069.    ISPPP must address.  In particular, it addresses the issues of
  1070.    simplicity, transparency, efficiency, packet framing, protocol
  1071.    multiplexing, error detection, standard MTUs, symmetry, switched and
  1072.    non-switched media, connection status, network address negotiation
  1073.    and future extensibility.  However, the XNS SPPP does not meet our
  1074.    requirements for multiple data link layer protocols, fault detection
  1075.    and data compression negotiation.  Although protocol multiplexing is
  1076.    provided, the packet type field has only 8 bits which is too few.
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103. Perkins                  expires in six months                 [Page 18]
  1104. DRAFT             Point-to-Point Protocol Requirements   September 1993
  1105.  
  1106.  
  1107. References
  1108.  
  1109.    [1]   Postel, J., "Internet Protocol", RFC-791, USC/Information
  1110.          Sciences Institute, September 1981.
  1111.  
  1112.    [2]   Postel, J., "User Datagram Protocol", RFC-768, USC/Information
  1113.          Sciences Institute, August 1980.
  1114.  
  1115.    [3]   Electronic Industries Association, EIA Standard RS-232-C,
  1116.          "Interface Between Data Terminal Equipment and Data
  1117.          Communications Equipment Employing Serial Binary Data
  1118.          Interchange", August 1969.
  1119.  
  1120.    [4]   Mills, D. L., "DCN Local-Network Protocols", RFC-891, December
  1121.          1983.
  1122.  
  1123.    [5]   Farber, David J., Delp, Gary S., and Conte, Thomas M., "A
  1124.          Thinwire Protocol for Connecting Personal Computers to the
  1125.          Internet", RFC-914, University of Delaware, September 1984.
  1126.  
  1127.    [6]   Finn, G., "Reliable Asynchronous Transfer Protocol (RATP)",
  1128.          RFC-916, USC/Information Sciences Institute, October 1984.
  1129.  
  1130.    [7]   Robinson, J., "Reliable Link Layer Protocols", RFC-935, BBN,
  1131.          January 1985.
  1132.  
  1133.    [8]   Braden, R., and J. Postel, "Requirements for Internet
  1134.          Gateways", RFC-1009, USC/Information Sciences Institute, June
  1135.          1987.
  1136.  
  1137.    [9]   Romkey, J., "A Nonstandard for the Transmission of IP Datagrams
  1138.          Over Serial Lines: SLIP", RFC-1055, June 1988.  RFC-1009,
  1139.          USC/Information Sciences Institute, June 1987.
  1140.  
  1141.    [10]  ISO International Standard (IS) 3309, "Data Communications -
  1142.          High-level Data Link Control Procedures - Frame Structure",
  1143.          1979.
  1144.  
  1145.    [11]  CCITT Recommendation X.25, "Interface Between Data Terminal
  1146.          Equipment (DTE) and Data Circuit Terminating Equipment (DCE)
  1147.          for Terminals Operating in the Packet Mode on Public Data
  1148.          Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.
  1149.  
  1150.    [12]  CCITT Recommendation Q.921 "ISDN User-Network Interface Data
  1151.          Link Layer Specification".
  1152.  
  1153.    [13]  Romkey, J.L., "PC/IP Programmer's Manual", Massachussetts
  1154.          Institute of Technology Laboratory for Computer Science,
  1155.  
  1156.  
  1157.  
  1158. Perkins                  expires in six months                 [Page 19]
  1159. DRAFT             Point-to-Point Protocol Requirements   September 1993
  1160.  
  1161.  
  1162.          January 1986.
  1163.  
  1164.    [14]  Xerox Corporation, "Synchronous Point-to-Point Protocol", Xerox
  1165.          System Integration Standard, Stamford, Connecticut, XSIS
  1166.          158412, December 1984.
  1167.  
  1168.    [15]  "Digital Data Communications Message Protocol", Digital
  1169.          Equipment Corporation.
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196.  
  1197.  
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213. Perkins                  expires in six months                 [Page 20]
  1214. DRAFT             Point-to-Point Protocol Requirements   September 1993
  1215.  
  1216.  
  1217. Chair's Address
  1218.  
  1219.    The working group can be contacted via the current chair:
  1220.  
  1221.       Fred Baker
  1222.       Advanced Computer Communications
  1223.       315 Bollay Drive
  1224.       Santa Barbara, California, 93111
  1225.  
  1226.       EMail: fbaker@acc.com
  1227.  
  1228.  
  1229. Author's Address
  1230.  
  1231.    Questions about this memo can also be directed to:
  1232.  
  1233.       Drew Perkins
  1234.       4015 Holiday Park Drive
  1235.       Murrysville, PA  15668
  1236.  
  1237.       EMail: perkins+@cmu.edu
  1238.  
  1239.  
  1240. Editor's Address
  1241.  
  1242.    Typographic revision and historical notes by:
  1243.  
  1244.       William Allen Simpson
  1245.       1384 Fontaine
  1246.       Madison Heights, Michigan  48071
  1247.  
  1248.       EMail: Bill.Simpson@um.cc.umich.edu
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268. Perkins                  expires in six months                 [Page 21]
  1269. DRAFT             Point-to-Point Protocol Requirements   September 1993
  1270.  
  1271.  
  1272.                            Table of Contents
  1273.  
  1274.  
  1275.      1.     Introduction ..........................................    1
  1276.         1.1       Definitions of Terms ............................    2
  1277.  
  1278.      2.     Requirements ..........................................    4
  1279.         2.1       Simplicity ......................................    4
  1280.         2.2       Transparency ....................................    5
  1281.         2.3       Packet Framing ..................................    5
  1282.         2.4       Bandwidth Efficiency ............................    5
  1283.         2.5       Protocol Processing Efficiency ..................    5
  1284.         2.6       Protocol Multiplexing ...........................    6
  1285.         2.7       Multiple Physical and Data Link Layer
  1286. Protocols .........................................................    6
  1287.         2.8       Error Detection .................................    6
  1288.         2.9       Standardized Maximum Packet Length (MTU) ........    7
  1289.         2.10      Switched and Non-Switched Media .................    7
  1290.         2.11      Symmetry ........................................    7
  1291.         2.12      Connection Liveness .............................    7
  1292.         2.13      Loopback Detection ..............................    8
  1293.         2.14      Misconfiguration Detection ......................    8
  1294.         2.15      Network Layer Address Negotiation ...............    9
  1295.         2.16      Data Compression Negotiation ....................    9
  1296.         2.17      Extensibility and Option Negotiation ............   10
  1297.  
  1298.      3.     Non-Requirements ......................................   11
  1299.         3.1       Error Correction ................................   11
  1300.         3.2       Flow Control ....................................   11
  1301.         3.3       Sequencing ......................................   11
  1302.         3.4       Backward Compatibility ..........................   11
  1303.         3.5       Multi-Point Links ...............................   12
  1304.         3.6       Half-Duplex or Simplex Links ....................   12
  1305.         3.7       7-bit Asynchronous RS-232 Links .................   12
  1306.  
  1307.      4.     Prior Work On PPP Protocols ...........................   13
  1308.         4.1       Internet Protocols ..............................   13
  1309.            4.1.1  RFC 891 - DCN Local-Network Protocols,
  1310. Appendix A ........................................................   13
  1311.            4.1.2  RFC 914 - Thinwire Protocols ....................   13
  1312.            4.1.3  RFC 916 - Reliable Asynchronous Transfer
  1313. Protocol ..........................................................   14
  1314.            4.1.4  RFC 935 - Reliable Link Layer Protocols .........   14
  1315.            4.1.5  RFC 1009 - Requirements for Internet Gateways
  1316.            4.1.6  RFC 1055 - Serial Line IP .......................   14
  1317.         4.2       International Protocols .........................   15
  1318.            4.2.1  ISO 3309 - HDLC Frame Structure .................   15
  1319.            4.2.2  ISO 6256 - HDLC Balanced Class of Procedures
  1320.  
  1321.  
  1322.  
  1323. Perkins                  expires in six months                [Page iii]
  1324. DRAFT             Point-to-Point Protocol Requirements   September 1993
  1325.  
  1326.  
  1327.            4.2.3  CCITT X.25 and X.25 LAPB ........................   15
  1328.            4.2.4  CCITT I.441 LAPD ................................   16
  1329.         4.3       Other Protocols .................................   16
  1330.            4.3.1  cisco Systems point-to-point protocols ..........   16
  1331.            4.3.2  MIT PC/IP framing protocol ......................   17
  1332.            4.3.3  Proteon p4200 point-to-point protocol ...........   17
  1333.            4.3.4  Ungermann Bass point-to-point protocol ..........   17
  1334.            4.3.5  Wellfleet point-to-point protocol ...............   18
  1335.            4.3.6  XNS Synchronous Point-to-Point Protocol .........   18
  1336.  
  1337.      REFERENCES ...................................................   19
  1338.  
  1339.      CHAIR'S ADDRESS ..............................................   21
  1340.  
  1341.      AUTHOR'S ADDRESS .............................................   21
  1342.  
  1343.      EDITOR'S ADDRESS .............................................   21
  1344.  
  1345.  
  1346.  
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.